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METHODS AND APPARATUS FOR to determine whether each of the storage systems to which 

PERFORMING MASS OPERATIONS ON A the configuralion request is sent is adapted, either physically, 

PLURALITY OF MANAGED DEVICES ON A logically, or both, to implemeat the configuration request. 

NETWORK Thus, what is needed is a system which can process mass 

5 operations with a plurality of managed devices which may 

CROSS-REFERENCES TO RELATED be manufactured by different companies or may running 

APPLICATIONS diiferent versions of controller management software, and a 

ry, . ,. - , . , „ ... ,^i„.„j system which can perform the proper error checking to 

This application is being filed concurrently with related ■' . j j - ■ i . *u 

/\ 1- ^ nnnen'jA't «i ^ i ,i q cusurc that the managed devices can implement the mass 

U.S. patent applications: Ser. No. 09/350,742 hied Jul. 9, . ^ *^ 

1999, entitled "Methods and Apparatus for Issuing Updates operation request. 

to Multiple Management Entities"; Ser. No. 09/350,739 filed SUMMARY OF THE INVENTION 

Jul. 9, 1999, entiUed ^'Methods and Apparatus for Managing According to the invention, a method of configuring a 

Heterogeneous Storage Devices"; Ser. No. 09/350,735 filed plurality of managed devices. The method preferably 

Jul. 9, 1999, entitled "Methods and Apparatus for Commit- includes selecting a source managed device, obtaining a 

ting Configuration Changes to Managed Devices Prior to source configuration description from the source managed 

CorapletioQ of the Configuration Change", Ser. No. 09/350, device, selecting one or more destination managed devices 

945 filed Jul. 9, 1999, entitled "Platform Neutral Data configured, issuing a configuration change command 

Storage Management Method and Apparatus"; Ser. No. ^^ch of the selected destination managed devices and 

09/350,515 filed Jul. 9, 1999, entitled "Methods and Appa- applying the source configuration description selected from 

raius for Managing Devices Without Network Attach- the source managed device to each of the selected destina- 

ments"; and Ser. No. 09/350,753 filed Jul. 9, 1999, entitled tj^n managed devices. 

"Apparatus and Method for a Computer Management Stor- accordance one particular embodiment of the present 

age System", all of which are incorporated herem by refer- invcndon. the method may include the step of editing the 

25 source configuration description before issuing the configu- 

BACKGROUND OF THE INVENTION ration change commands to the one or more destination 

managed devices. 

The present invention relates generally to methods and accordance with yet another embodiment of the present 

apparatus for performing a mass operation on a plurality of invention, the method may further include an error checking 

managed devices on a network, and more particularly to a ^^^^^^ ^^ich includes the step of determining whether (he 

system and method in which the same operation, such as a ^^^^^^ configuration description can be appUcd to each of 

particular system configuration operation can be performed the one or more destination managed devices. In accordance 

on a plurality of managed devices from a single request. ^^j^ ^p^^-t of the error checking routine, the method 

Network computing systems typically require a variety of includes checking the destination managed devices' hard- 
devices to construct and maintain a working storage system, ware configuration to determine whether the hardware con- 
In addition, companies with large networks typically have a figuration meets the hardware configuration constraints of 
number of different storage systems, many of which can be the source configuration description. In addition, the error 
manufactured by different companies and/or run on different checking routine may include checking the destination man- 
versions of operating software. Storage system devices may aged devices' software to determine if the software can 
include, but are not limited to, host adapters, I/O chips, disk apply the source configuration description to the destination 
enclosures, and bridge controllers, to name a few. managed device. 

With these "heterogeneous" storage systems there exists in accordance with still another embodiment of the 

several management and configuration tasks that must be present invention, the step of selecting a source managed 

repeatedly executed across some subset of the managed device further includes the step of invoking in the managc- 
devices. These tasks are often tedious and potentially error 45 ment station, a source device management application asso- 

prone due to repeated user interaction. Thus, these tasks are ciated with the source managed device. TTie source device 

excellent targets for automation; that is, the ability to management application is for monitoring and managing the 

execute the plurality of tasks with a single command request. source managed device. Preferably, the management station 

Mass operations are special management commands utilizes the source device management application to obtain 
which can be performed by management software to a 50 the source configuration description from the source man- 
specified subset of managed devices in a given domain. A aged device. 

prose example of a mass operation may be "managed device In addition, the step of selecting one or more destination 
A and managed device B please make a volume of size 2 GB managed devices further includes the step of invoking a 
at protection level 5 on yourselves." By instructing a series destination device management application in the manage- 
of machines to conduct a given task in parallel, the lime S5 ment station for each of the one or more destination man- 
required to administer an enterprise can be greatly reduced. aged devices. Each of the destination device management 
Unfortunately, mass operations present several problems applications preferably are associated with at least one of the 
when attempting to execute them in an enterprise manage- one or more destination managed devices. Also, the desti- 
ment paradigm. In particular, the addition of mass operations nation device management applications are for monitoring 
to management software may cause stability problems with 60 and managing the at least one of the one or more destination 
the software. In addition, it is difiScult to .submit mass managed devices with which each of the destination device 
operation task requests to devices manufactured by different management applicatioas arc associated. Preferably, each of 
companies or running different versions of controller man- the destination device management applications are used to 
agement software because they all require different man- issue the configuration change commands to at least one of 
agement and configuration commands. Finally, when 65 said one or more destination managed devices with which 
issuing, for example, storage system configuralion requests each of the destination device management applications are 
to a plurality of storage systems on a network, it is difficult associated. 
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In accordance with another embodiment of the present 
invention, each of the one or more destination managed 
devices preferably include a controller, which is adapted to 
apply the source configuration description in the destination 
managed devices. Once the controller has finished the con- 
figuration update^ it preferably informs the destination 
device management application associated with the destina- 
tion managed device that the configuration change request 
has been processed. 

In accordance with yet another embodiment of the present 
invention, the management station, by running one of the 
destination device management applications, is adapted to 
display a configuration and status of the destination man- 
aged device with which the destination device management 
application is associated. Thus, when the controller informs 
the destination device management application that the 
configuration change request was processed, the controller 
also informs the device management application of the new 
configuration and status of the destination managed device. 
Accordingly, the destination device management appUcation 
causes the new configuration and status of the destination 
managed device to be displayed on the management station. 

A more complete understanding of the present invention 
may be derived by referring to the detailed description of 
preferred embodiments and claims when considered in con- 
nection with the figures, wherein like reference numbers 
refer to similar items throughout the figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a schematic diagram of a network having various 
storage systems and storage management stations; 

FIG. 2 is a schematic diagram of a network having a 
management station, which accesses management applica- 
tion programs stored in an appUcation repository storage 
area connected to the management station; 

FIG. 3 is a schematic diagram of a network having a 
management station, which accesses management applica- 
tion programs stored in an application repository storage 
area connected to a network; 

FIG. 4 is a schematic diagram of a network having a 
management station, which accesses management applica- 
tion programs stored on the storage system or device being 
managed by the management station; 

FIG. 5 is a block diagram illustrating various devices 
residing on a network and their associated software compo- 
nents; 

FIG. 6 is a drawing of a sample user interface screen of 
a discover-monitor application program; 

FIG. 7 is a drawing of a sample user interface screen of 
a storage system management application program; 

FIG. 8 is a flow diagram illustrating start-up processes of 
a discover-monitor application program and a storage .sys- 
tem management application program; 

FIG. 9 is a flow diagram illustrating a process of creating 
a volume on a storage system; 

FIG. 10 is a flow diagram illustrating a process of 
replicating the configuration of one storage system to 
another storage system; 

FIG. 11 is a flow diagram illustrating a process of per- 
forming a mass operation on multiple storage systems on a 
network; 

FIG. 12 is a flow diagram illustrating a validity checking 
scheme performed by the process of FIG. 10; 

FIG. 13 is a flow diagram illustrating a process of 65 
reporting events from a storage system to a management 
station; 



FIG. 14 is a flow diagram illustrating a process of a 
managed entity broadcasting configuration updates to a 
plurality of management devices; 

FIG. 15 is a flow diagram illustrating how a management 
device issues management commands to managed entities 
and receives configuration update information from man- 
aged entities; and 

FIG. 16 is a flow diagram illustrating a process of 
committing configuration changes prior to the completion of 
a long term event. 

DESCRIPTION OF THE SPECIFIC 
EMBODIMENTS 
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Introduction 

The present invention relates generally to methods and 
apparatus for managing devices on a network. More 
particularly, the present invention relates to a system and 
software for monitoring, configuring and managing hetero- 
geneous storage systems on a network using a single man- 
agement application residing on one or more management 
stations. 

While the present invention disclosed herein refers par- 
ticularly to storage systems, it should be appreciated that the 
management systems and applications of the present inven- 
tion can be used to manage a wide variety of devices on a 
network, including workstations, servers, and other suitable 
I/O devices. Thus, the present invention relates to a man- 
agement system and applications which have a single user 
interface for managing network devices, and which can 
interact with currently existing management frameworks, 
such as Hewlett-Packard's OpenView, IBM's NetFinity and 
Computer Associates' Uniccnter, to name a few. Finally, the 
present invention preferably utilizes platform-independent 
technologies, such as Java and Java run-time environments, 
so that the particular network architecture, and workstation 
and server platfonms on the network are irrelevant. 

System Overview 

The present invention comprises a device-independent 
management framework which supports device-specific 
management applications. The framework preferably com- 
prises an application that implements a common graphical 
user interface that is used to manage all I/O devices in an 
enterprise or on a network. Preferably, at the start of a day, 
the management framework discovers all 1/0 devices in the 
enterprise and displays them, cither by physical 
connectivity, or by logical association. The discovery pro- 
cess can be conducted manually by a user, or it can occur 
automatically For each distinct device type being managed 
or configured, a unique management application preferably 
is loaded, thus giving the framework the ability to under- 
stand device -specific management tasks. Finally, because 
the architecture gives the management framework the ability 
to communicate with all I/O devices on the enterprise, 
operations such as "firmware upgrades" may be performed 
en mass to common device types. 

Referring now to FIG. 1, a system 100 is shown embody- 
ing the present invention. In particular, system 100 prefer- 
ably comprises a local area network 102, a plurality of 
storage systems 104-110, an I/O management station 112, a 
desktop management interface (DMl) management station 
114, and a simple network management protocol (SNMP) 
management station 116. In addition, network 102 may be 
connected to other enterprise or company networks located 
in remote areas either via direct telephone links or, as 
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illustrated in FIG. 1, through a larger network, such as the 
Internet 118, or the like. For simphcity, FIG. 1 merely shows 
network 102 being connected to a storage management 
station 120 through Internet 118, but as one skilled in the art 
will appreciate, storage management station 120 may be a 
single device connected to Internet 118, or storage manage- 
ment station 120 may be a device on a network in a remote 
location connected to network 102 via the Internet. In any 
event, the purpose of FIG. 1 is to illustrate that the man- 
agement framework of the present invention may be used on 
local area networks, as well as on wide area networks and 
with remote access devices. 

Storage systems 104-110 may comprise any suitable 
storage system, such as file servers, disk farms, RAID 
systems, and the Itkc. In addition, the storage systems may 
comprise controllers which connect directly to network 102 
or the storage systems may be connected to network 102 
through a computer server. FIG. 1 illustrates a number of 
different types of storage system configurations which may 
reside on a network. However, the configurations illustrated 
in FIG. 1 do not illustrate all the storage system 
configurations, and thus, the present invention is not limited 
to the illustrated embodiments. 

Still referring to FIG. 1, the various embodiments of 
storage systems 104-110 illustrated in FIG. 1 will now be 
discussed. In particular, storage system 104 preferably com- 
prises a RAID storage system which includes a server 122 
and a plurality of disk drives 124 connected to server 122. 
In accordance with this particular embodiment, the proces- 
sor of server 122 preferably acts as the RAID control device 
for storage system 104. In this manner, the RAID control 
software preferably is stored, either on disks 124 or within 
internal storage of server 122 and is processed by server 122 
during operation of the storage system. Disks 124 may be 
connected to server 122 by any number of connection means 
126, such as fiber channel, SCSI, PCI, USB, Firewire, or the 
like. Server 122 preferably is connected to network 102 via 
well-known network connection means. 

Like storage system 104, storage systems 106 and 108 
also preferably comprise RAID storage devices. However, 
instead of the server acting as the controller for the RAID 
storage system, the storage systems preferably include their 
own controllers 128 and 130, which preferably are con- 
nected to servers 132 and 134 via PCI bus connections 136 
and 138, respectively. Thus, the storage system control 
functions for storage systems 106 and 108 preferably are 
performed by controllers 128 and 130, respectively. While 
controllers 128 and 130 are illustrated as being separate 
from the RAID disk farm or disk array 140, one skilled in 
the art will appreciate that controllers 128 and 130 may 
reside within the enclosure of disk farm 140. Alternatively, 
controllers 128 and 130 may be configured as co-processors 
within servers 132 and 134, respectively. 

As illustrated in FIG. 1, controller 128 of storage system 
106 and controller 130 of storage system 108 are not 
connected directly to network 102, but are connected to the 
network via servers 132 and 134, respectively. With this 
particular configuration, it is difiEcult for a management 
device to locate the storage system controllers 128, 130 
connected to servers 132, 134, and thus, it is difficult to send 
management commands to the storage system controllers. 
However, as discussed in more detail below, servers 132 and 
134 preferably include a layer of software which converts 
requests from the I/O management stations 112, 120 into 
command packets which are delivered to controllers 128 and 
130 and which can be understood and processed by the 
controllers. 
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Storage system 110 also preferably comprises a RAID 
storage system having an independent RAID storage con- 
troller 142. However, in this particular embodiment, storage 
controller 142 preferably includes a network attachment 

5 means 144, so that it can attach directly to network 102. In 
addition, as illustrated in FIG. 1, controller 142 may be 
connected to a server 146 via a proxy 1/0 bus 148, such as 
a SCSI or Fibre Channel bus. In this manner, storage 
management stations 112, 120 can issue management com- 
mands direcdy to storage controller 142 via network 102, or 
they can issue management commands through server 146 
and across proxy I/O bus 148. As with the PCI attached 
controllers in storage systems 106 and 108, if access to 
controller 142 is through server 146 and across proxy 1/0 
bus 148, server 146 preferably includes a layer of software 
configured to convert requests from storage management 
stations 112, 120 to command packets which can be received 
and processed by controller 142. While controller 142 
appears to be separate from the RAID storage device 150, 
one skilled in the art will appreciate that controller 142 may 
be configured within the disk enclosure of device 150. 

As illustrated in FIG. 1, in addition to storage manage- 
ment stations 112, 120, system 100 also may include other 
network management devices, such as a desktop managc- 

25 ment interface (DMI) management station 114 and a simple 
network management protocol (SNMP) management station 
116. In addition, other third party management stations, such 
as Hewlett-Packard's Open View, Computer Associates' 
Unicenter, IBM's NetFinity, and/or Microsoft's Microsoft 

3Q Management Console, may be attached to network 102. 
Thus, the present invention is not hmited to the illustrated 
embodiment. 

In accordance with a preferred embodiment of the present 
invention, 1/0 management stations 112, 120 may comprise 

35 any suitable computer workstation running on any operating 
system platform. For example, I/O management stations 
112, 120 may run on Microsoft's Windows or NT platforms, 
Apple's Macintosh platfonm, a Unix platform, or the hke. 
Thus, in order for I/O management stations 112, 120 to 

40 process the management apphcations associated with each 
of the storage systems regardless of the I/O management 
station platform, it is preferable that I/O management sta- 
dons 112, 120 are equipped with a Java-comphant web 
browser or other suitable Java run-time environment. Thus, 

45 as one skilled in the art will appreciate, if the management 
application programs for each of the storage systems arc 
written in Java, the operating system environment of 1/0 
management stations 112, 120 is irrelevant. That is, the Java 
applications can run in any environment, as long as it is a 

50 Java-compliant environment. 

Referring now to FIG. 2, a more simplified version of a 
management system framework 200 is illustrated. System 
200 preferably comprises a network 202 with a plurality of 
managed devices 204-1 to 204-N connected thereto. In 

55 accordance with this particular embodiment of the present 
invention, managed devices 204 may comprise storage 
systems or other suitable I/O devices. In addition, an I/O 
management station 206 preferably is connected to network 
202 and configured to monitor, configure, and manage 

60 devices 204 on the network. 

As illustrated in FIG. 2, device 204-1 preferably includes 
control software which uses a management application 
interface program labeled "A." Similarly, devices 204-2 and 
204-3 run control software which use a management in ter- 
es face application program labeled "B." Finally, device 204-N 
preferably runs control software which uses a management 
interface application program labeled "X." In addition, 
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system 200 preferably includes a storage system 210 which 204 is updated, for example to a new versioD, preferably a 

comprises a management applet repository 212 for holding new management interface application program is added to 

a plurality of management interface application programs the management interface application program repository to 

214. As discussed briefly above, management interface go along with the updated control software, 

application programs 214 preferably arc Java applets which s accordance with an alternative embodiment of the 

can be run m any suitable Java run-Ume environment. ^^^^^^ invention, it may be preferable to only update small 

In accordance with one aspect of the present invenUon ^^^^^^^^ ^^^^ ^^^jrol software at any one time. For 

applet repository 212 may reside m internal storage of ^ ^^^-^^ ^^j^^ 

management station 206, or storage system 210 may be an J j ^^^.^.^^ definitions for drive 

external storage system connected directly to management , . , j j . * n * 

station 206 via communicadon link 216 CommuiUcation S^°"P^' ^"^^ ^^^^^"if^' 'f'^f^''^ controllers, storage 

link 216 may comprise any suitable communicaUon link ^V^^^^^' the like. Thus, if only small revisions are made 

between a work station and a storage system such as PCI, 1° "'^trol software of a device 204, only small modifi- 

SCSI, Fiber channel, USB, Firewire, or the like. Moreover, cations need to be made to the management interface 

in accordance with an alternative embodiment of the present appUcation program 214. Alternatively, mstead of changing 

invention and as illustrated in FIG. 3, storage system 210 the management interface application program 214, anew 

may be connected to network 202 via a suitable network management interface application program 214 may be 

connection 218. In accordance with this aspect of the added to repository 212 and may be run with the original 

invention, management station 206 preferably communi- interface application program, so that when the two man- 

cates with storage system 210 through network 202; for agement interface application programs are run together, 

example, along communication path 220. 20 they will be compatible with the updated control software of 

In accordance with one embodiment of the present the device, 

invention, a user can direct management station 206 to ,n accordance with another embodiment of the present 

discover all the devices on the network which are to be invention, instead of (he management interface application 

managed by the management station and displays the programs residing in a separate repository as illustrated in 

devices on the management station disp ay; i.e., a somewhat 25 the I/O device itself may act as the repository for the 

manual discovery process. In accordance with another ^^^^ , -^^^^^^^ ^ f,, R,f,,ring 

embodiment of the present invention, during the stail-up of ^ ^ ^ illustrated in which the 

management station 206, managemenl station pre erably -^^^^^^^^ application programs for a particular 

nins an application 208 which automatical y locates all device actually reside on that device. In accordance with this 

devices 204 residing on network 202, and displays the list of 30 . . r.L . ^ Ann e ui 

^ , ^ embodiment of the present invention, system 400 preferably 

devices on management station 206. Inus, when manage- _ . . , , . . , 

. . r^nr ■ J- . J . c comprises a network 402, an I/O device 404, such as a 

ment station 206 is directed to manage, monitor or configure , ^ . , i , Anc 

. , -rt* ' . . tixt: Storage system, and a managemenl station 406. 

a device 204 on network 202, management station 206 » ^ > o 

preferably uses information obtained during the locate pro- While device 404 may be any suitable I/O device, for the 

cess to match a particular device 204 with the appropriate 35 Purposes of this example, device 404 preferably is a RAID 

management appUcation 214 residing in repository 212. ^'o^age system. Accordingly, RAID storage system 404 

Once a match is made, management station 206 preferably comprises a RAID controller 406 and a plurality of storage 

retrieves the appropriate management application 214 and ^"^^s Preferably, a management mterfacc application 

processes it on the station. As discussed in more detail program for RAID device 414 is stored man area 410 on one 

below, the retrieved management application 214 then per- 40 '^^^'^ ""'f^.^Tn fSi'? 

forms the necessary functionality to manage, monitor, and/ discovers RAID device 404 on network 402, RAID device 

or configure the particular device. Each management inter- ^04 and in particular RAID controller 406, preferably passes 

face application program 214 preferably is configured to the management mterface application program from area 

communicate with and direct the controller, and in particular ^10 on drives 408 to management station 406 across net- 

the control software, of the associated device 204. For 45 ^""'^ i^ciU^it this transfer, RAID controller 406 

example, management interface application program 214-A Preferably includes an application 412 which allows it to act 

is specifically designed to monitor and communicate man- ^s an embedded web server, givmg it the ability to pass the 

agement and/or configuration commands to device 204-1. management interface application program to ma^ement 

Similariy, management interface application program 214-B station 406 using a web server protocol, such as HTTP or the 

is configured to monitor and communicate management 50 ^^'^ controller 406 wiU act like any 

and/or configuration commands to devices 204-2 and 204-3, other web server on a network or on the Internet, passmg 

and management interface application program 214-X is J^^* ''y**^ «»de programs to a work station having 

configured to monitor and communicate management and/or ^ browser or other suitable Java run-Ume environment. 

configuration commands to device 204-N. With this particu- * o r . 

, . r. 1..- ji A ■ System Software Components 

lar configuration, if at some later time a managed device 204 55 

is updated to a new level of software that requires a different Referring now to FIG. 5, software components of a 

management interface program 214 to manage that device, management system 500 now will be discussed. In accor- 

or if a new managed device 204 of a different device type is dance with the embodiment of the present invention illus- 

added to the system, the software residing in the updated traied in FIG. 5, system 500 preferably comprises a network 

managed device or the new managed device will indicate the 60 502, a network attached I/O device 504, a proxy attached 1/0 

particular managemenl interface application program 214 device 506 attached to network 502 via server 508, an I/O 

with which it is compatible. Thus, management station 206 management station 510, and one or more third party 

will be able to determine which management information management frameworks 512. Wile I/O devices 504 and 506 

application program 214 residing in repository 212 should may comprise any suitable I/O device on a network, for (he 

launch for a given managed device 204 on network 202. 65 purpose of this example, I/O devices 504 and 506 preferably 

In accordance with a preferred embodiment of the present comprise RAID storage systems. In addition, as illustrated in 

invention, when the control software of a managed device FIG. 5, other manageable devices 514 may be connected lo 
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server 508. The other manageable devices 314 may com- 
prise any suitable peripheral device, such as a host bus 
adapter, just a bunch of disks (JBOD), a SCSI device, or the 
like. 

The following discussion sets forth software elements 
which preferably reside within each of the devices on system 
500. While system 500 is described herein as having a 
network attached RAID device 504, a proxy attached RAID 
device 506, and a server 508, one skilled in the art will 
appreciate that other I/O device connections to network 502 
may be used; for example, the other network attachment 
configurations illustrated in FIG. 1 and disclosed above. 
Thus, the present invention is not limited to the configura- 
tion of FIG. 5. 

Management Station Software Components 
Discover-Monitor Applet 

As mentioned briefly above, management station 510 
preferably comprises a Java compliant web browser, or 
alternatively, another suitable Java run-time compliant envi- 
ronment for running Java applet programs. Preferably one of 
the application programs which management station 510 
processes is a discovcr-monitor application or applet 516. 
Discover-monitor applet 516 preferably is a Java applet 
which is stored in nonvolatile memory in management 
station 510, or in an applet repository residing on network 
502. Preferably, discovcr-monitor applet 516 can run under 
either a Java compliant web browser or under an operating 
system's Java nm-time environment. 

Discover-monitor applet 516 performs, inter alia, the 
following functions: 

(1) Discovering managed devices on network 502 and 
presenting them on the management station display; 

(2) Understanding and maintaining an association 
between the discovered managed devices and the spe- 
cific management interface application program it 
requires; 

(3) Providing a user interface for invoking the manage- 
ment interface application program for a particular 
managed device, which in turn, presents a more 
detailed interface for managing the device; and 

(4) Listening for events from discovered devices and 
providing notifications, both on-screen visual, as well 
as via remote e-mail, of device slate changes (e.g., 
"optimal," "needs attention," or "unresponsive"). More 
detailed device notifications may be provided by the 
management interface application programs them- 
selves. 

In accordance with the present invention, discover- 
monitor applet 518 preferably is designed to allow coexist- 
ence of different management interface application pro- 
grams for different types of devices, and within a device 
type, to permit coexistence of interface application programs 
at different versions of a device's management interface 
software. Thus, new hardware can be introduced and old 
hardware can be phased out at a user's convenience without 
the risk of introducing management incompatibilities. 
Management Interface Application Programs 
Management interface application programs 518 prefer- 
ably are Java applets which arc device type and version 
specific program components. A particular management 
interface application program 518 knowrs how to manage an 
individual device of its associated type, and is responsible 
for presenting the detailed, device-specific management 
operations to a user. In accordance with a preferred embodi- 
ment of the present invention, discover-monitor applet 516 
preferably locates and loads the correct management inter- 
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face application program 518 from storage, based on its 
knowledge of the managed device's management interface 
version. Generally, management interface application pro- 
grams 518 display the current state, status and configuration 

S of a device with which it is associated. In addition, man- 
agement interface application programs 518 preferably 
include logic which allows a user to submit management and 
configuration commands to the managed device. A more 
detailed discussion of how management interface applica- 

10 tion programs 518 operate is discussed below. 
Server Based Software Components 

In accordance with the present invention, the two main 
purposes of the server based software components are to: (1) 
Interface proxy attached controllers to the network so they 

15 can be managed by management station 510; and (2) Inter- 
face the managed devices to other industry standard man- 
agement protocols and products. Preferably, the server based 
software components comprise a conversion application for 
converting RPC commands to a standard I/O read/write 

20 mechanism, and a DMI and/or SNMP interface application. 
RPC Conversion Agent 

RPC conversion agent 522 preferably comprises a thin 
piece of server 508 resident software preferably written in 
Java and executing under an operating system's Java run- 

25 time environment. The purpose of RPC conversion agent 
522 is to support remote procedure call (RPC) traffic 
between the management interface application program 518 
running on management station 510 and a proxy attached 
storage controller 506 (i.e., a storage controller that does not 

30 have its own network connection). As one skilled in the art 
will appreciate, a storage system connected to a server, for 
example via a PCI connection, does not communicate with 
the server using RPC, but using a standard I/O read/write 
mechanism, such as a SCSI command interface. Thus, for 

35 the management application program 518 to communicate 
with controller 506, RPC conversion agent 522 preferably is 
configured to receive RPC commands from a management 
interface application program 518 and convert the RPC 
command to a protocol which storage controller 506 will 

40 understand. In this particular example, the RPC conversion 
agent 522 encapsulates RPC messages within I/O write 
commands to send them to the direct- attached controller 506 
via I/O path 524. Similarly, the RPC conversion agent 522 
receives RPC responses from controller 506 via I/O read 

45 commands, extracts the RPC responses from the 1/0 read 
commands and forwards the RPC responses to management 
application program 518. In accordance with a preferred 
embodiment of the present invention, the protocol for encap- 
sulating RPC messages within read/write commands is a 

50 Universal Transport Mechanism (UTM), a protocol devel- 
oped by LSI Logic Corporation, located in Milpitas, Calif. 
RPC conversion agent 522 allows all management interface 
programs 518 to be written the same, regardless of whether 
the storage controller has a direct network connection or not. 

55 If the storage controller is not directly attached to the 
network, RPC conversion agent 522 performs the proper 
protocol conversion. 

Olhcr Management Framework Agent 

Server 508 also preferably includes software to interface 

60 server 508 and other connected devices with other third 
parly management frameworks or protocols, such as desktop 
management interface (DMI), simple network management 
protocol (SNMP) and/or common information model (CIM). 
in accordance with this aspect of the present invention, 

65 server 508 preferably includes a management framework 
agent 526, which comprises one or more applications which 
facilitate communication between management stations like 
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DMI, SNMP and/or CIM stations and devices connected to 
server 508. For example, in the case where DMI is used, 
agent 526 preferably comprises one or more DMI applica- 
tions which enables devices to be managed within a DMI 
conformant management framework. The DMI architecture 
allows a device to deliver events to, respond to management 
information requests from, and even to be controlled by a 
DMI conformant management application. 

Server 508 also preferably supports the SNMP and CIM 
architectures. In accordance with this aspect of the present 
invention, agent 526 on server 508 preferably includes an 
SNMP framework application and/or a CIM framework 
application. In this manner, an SNMP or CIM management 
station can send requests to and receive event notifications 
from a device connected to server 508. DMI, SNMP and 
CIM interface agents are known in the art, and thus, will not 
be described further herein. 
Controller-Based Software Components 

Device controllers 504 and 506 both preferably include a 
management protocol 528 and a RAID engine 530. In 
addition, network attached controller 504 preferably 
includes an RPC-to-intemal-messaging component 532 and 
a controller embedded DMI, SNMP and/or CIM service 
provider 534. In addition, proxy attached controller 506 
preferably includes a UTM-to-internal messaging compo- 
nent 536. 

Management Protocol 

The architecture of the present invention is centered 
around an object model of the managed devices, which is the 
basis for communication between management station 510, 
and in particular management interface application program 
528, and the devices (504, 506). The object model preferably 
is the actual physical and logical configuration of the device. 
In the storage array case, the object model of the storage 
array is handled by the controller via a management protocol 
528. An example of a suitable management protocol is LSI 
Logic's SYMbol (symbios browser-oriented language) pro- 
tocol. Management protocol 528 preferably receives high- 
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UTM-io-Intemal-Messaging 

As discussed briefly above, proxy attached controller 506 
preferably includes a UTM-to-intemal-messaging compo- 
nent 536. UTM-to-intcrnal messaging component 536 pref- 
erably is part of the controller firmware for proxy attached 
controller 506, and is responsible for providing management 
protocol packet transport over the block read/write path 
between server 508 and controller 506. This communication 
preferably is bi-directional, allowing commands to be trans- 
ported into and responses to be transported out of controller 
506. 

As discussed above, management interface application 
programs 518 preferably communicate using the RPC pro- 
tocol. In the proxy attached controller 506 case, controller 
506 communicates with server 508 using UTM, so RPC 
conversion agent 522 in server 508 converts the RPC 
commands to the UTM format before communicating with 
controller 506. Upon receiving the UTM packets, UTM-to- 
internal-mcssaging component 536 preferably converts the 
UTM packets to packets and commands which can be 
understood by management protocol 528. Thus, UTM-to- 
inlernai-messaging component 536 in essence comprises a 
UTM interface for controlling communications between 
server 508 and controller 506, and an internal controller 
mechanism for controlling command and event noliflcation 
dispatch to and from management protocol server 528. 

White a preferred embodiment of the present invention is 
described herein as using UTM to communicate between 
server 508 and device 506, one skilled in the art will 
appreciate that other I/O readAvrite mechanisms, such as a 
SCSI command interface, may be used. Therefore, the 
present invention is not limited to the UTM embodiment. 

RP C-lo-Internal-Messaging 

As mentioned briefly above, network attached controller 
504 preferably includes an RPC-to-intemal -messaging com- 
ponent 532. RPC-to -internal-messaging component 532 
preferably is part of the network attached controller firm- 
ware which transports RPC transactions between the con- 
troller network port and the management protocol server 



level requests from management interface application (or 530. Preferably, packets crossing the controller network port 



applet) program 518 expressed in terras of the device object 
model, interprets the requests, carries out the requests by 
interacting with RAID engine 530 and then responds back to 
the management interface applet 518 in terms of the object 
model. The object model also defines events that originate 
with the managed device and flow to the management 
station 510; this event propagation is also the responsibility 
of management protocol 528. 
RAID Engine 

RAID engine 530 is the part of the storage controller 
firmware that is responsible for the core RAID 
implementation, independent of the host and drive interfaces 
with which it interacts. RAID engine 530 preferably com- 
prises a performance critical RAID read/write/caching com- 
ponent and a less-performance-critical configuration and 
management component. The configuration and manage- 
ment component, which is the focus and the content of the 
management architecture of the present invention, prefer- 
ably exhibits three main types of behavior: (1) carrying out 
management related tasks when directed to do so by the 
management station 510 and more specifically, management 
interface application program 518; (2) performing certain 
tasks automatically, either when necessary, or on a regular 
schedule (e.g., error and event logging and parity assurance); 
and (3) initiating notifications of important events, which are 
then propagated outside of the controller over network 502, 
either directly or via UTM in the proxy attached case. 
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interface 538 conform to standard RPC commands. At 
RPC-to-interaal-messaging component 532, the RPC com- 
mands are converted to the management protocol format 
528. Thus, the combination of the RPC conversion agent 522 
in server 508 and the UTM-to-intemal messaging compo- 
nent 536 in proxy attached controller 506 is the functional 
equivalent of the RPC-to-intcmal-messaging component 
532 of network attachment 504. That is, RPC conversion 
agent 522 and UTM-lo-interaal-mcssaging component 526 
effectively convert the RPC commands from management 
interface application 518 to the management protocol 528 
format. However, with the proxy attached controller 506, an 
additional protocol, preferably UTM between server 508 
and controller 506 is used. 

Controller Embedded DMI, SNMP and/or CIM Service 
Provider. 

Embedded service provider 534 in network attached con- 
troller 504 preferably is one or more software elements 
defined under the DMI, SNMP and/or CIM architectures. 
The embedded service provider 534 is configured to mediate 
between managed objects, such as controller 504, and a 
DMI, SNMP or CIM management application. By adding 
embedded service provider 534 within the network attached 
controller 504, controller 504 can interface with a DMI, 
SNMP or CIM management appHcation on network 502. 
DMI, SNMP and CIM management applications may reside 
within a separate management station, such as management 
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station 512, or the DM1, SNMP and CIM management 
applications may be applications or applets 520 which 
executes in the Java run-time environment of management 
station 510. 

User Interface 

As discussed briefly above, a user preferably interfaces 
with the management station 510 via a discovcr-monitor 
application program 516 and a management interface appli- 
cation program 518 for each of the devices on the network, lo 
Preferably, both the disco ver-monilor application 516 and 
each of the management interface application programs 518 
are Java programs or applets which run in a Java run-lime 
environment. 

Discover-raonitor Application 15 

Referring now to FIG. 6, a representation of a discover- 
monitor application screen 600 is illustrated. Preferably, 
discover monitor application screen 600 includes a manage- 
ment domain window 602, a detailed information window 
604, a status indicator 606 and a status line 608. 20 

In accordance with a preferred embodiment of the present 
invention, management domain window 602 presents a tree 
structured view of the complete management domain. 
Lower level nodes 610, 612 in the tree structure represent 
actual physical hardware devices such as servers, arrays, and 25 
other I/O devices. For example, as illustrated in FIG. 6, 
lower level node or server 612-1 includes two storage arrays 
610-1 and 610-2 attached thereto. Similarly, lower level 
node or server 612-2 includes a storage array 610-3 attached 
thereto. The higher level nodes in the tree represent the 30 
location of the hardware devices. For example, in the 
illustrated embodiment, the management domain is divided 
into two regions: a central region 618-1 and a southeast 
region 618-2. Within central region 618-1, the domain is 
further broken into states 616, for example, Kansas 616-1 35 
and Colorado 616-2. From there, the domain is further 
broken down into plant locations 614, for example, in 
Colorado 616-2, the illustrated company has locations in 
Colorado Springs 614-2 and Fort Collins 614-3. The man- 
agement domain shows the servers, storage arrays and other 40 
devices which exist on the networks of those locations. 

Detailed information window 604 preferably presents the 
detailed properties for each device in the management 
domain, based upon the particular node a user selects. 
Individual device nodes 610, 612 or a higher level location 45 
nodes 614, 616, 618 may be selected. When a location is 
selected, the detailed information window preferably 
includes an entry for each device in the subtree rooted at the 
selected location. When a specific device node is selected, 
detailed information window 604 di^lays certain device so 
specific attributes of the selected node. In addition, by 
double -clicking or selecting a specific device node, the 
device's associated management interface application pro- 
gram is launched. 

Status indicator 606 preferably includes a high level 55 
indication of whether or not any of the devices in the 
management domain have problems thai require attention. If 
all devices arc in working order, the status indicator pref- 
erably will indicate "optimal"; if there is a problem some- 
where in the management domain, the status indicator 606 60 
preferably will show that one or more devices require 
attention. Preferably the devices that have a problem will be 
indicated in the management domain window 602 by a 
highlighted color of that device, or an appearance change of 
the device icon. Finally, status line 608 preferably is an area 65 
for short pieces of context-sensitive information which the 
discover-monitor application program may wish lo display. 



While the discover-monitor application screen illustrated 
in FIG. 6 and disclosed herein presents information in a 
certain way and includes specific information, one skilled in 
the art will appreciate that the discover-monitor application 
screen may be designed and configured in any way. For 
example, the discover-monitor application screen may show 
additional information, or certain information that is dis- 
played in the discover-monitor application screen of FIG. 6 
may be eliminated. In addition, the information may be 
presented in a different way. Thus, the present invention is 
not limited to the specific embodiment of the discover- 
monitor application screen illustrated in FIG. 6. 
Management Interface Application 

Refenring now to FIG. 7, screen display 700 of a man- 
agement interface application or applet program is illus- 
trated. When a user selects and opens a particular device 
from the discovcr-monitor application screen, the manage- 
ment interface application program for that device is loaded 
into the management station, and a screen similar to screen 
700 preferably is displayed. Display 700 preferably includes 
a logical view window 702 and a physical view window 704. 

Logical view window 702 illustrates the logical compo- 
sition and properties of the selected device (e.g., storage 
array). The logical objects of the storage array are organized 
into a tree structure to make their interrelationships apparent. 
Screen 700 illustrates an example of a typical set of logical 
objects, including volume groups 706, volumes 708, free 
capacity regions 710, and unassigned capacity 712. 

Physical view window 704 preferably illustrates a view of 
actual hardware components in a particular device or storage 
array, e.g., controllers, drives, drive trays, disks, etc. 
Preferably, the physical view of the storage array displayed 
in physical view window 704 is an accurate graphical 
representation of the actual storage array device on the 
system. In this manner, the user can tell what the device 
looks like without being within visual range of the device. 
In the physical view 704, components in need of repair or 
replacement preferably will be distinguished by color and/or 
appearance changes. In addition, color or other visual dif- 
ferences may be used to indicate different roles or slates of 
disk drives (i.e., assigned, unassigned, hot, spare, etc.). As 
with discover-monitor output screen 600, management inter- 
face application screen 700 is not limited to the embodiment 
shown in FIG. 7. Additional information may be added, 
deleted, or the actual presentation of the information may 
vary. Thus, the present invention is not limited to the 
illustrated cmbodimenl. 

System Functionality 
Discover Monitor Applet Startup 

Referring now to FIG. 8, a flow diagram 800 is shown 
illustrating a start-up procedure for a discover-monitor 
application and a management interface application. Flow 
diagram 800 includes client or management station elements 
802, server elements 804, device controller elements 806, 
and web server elements 808. In accordance with a preferred 
embodiment of the present invention, when server 804 
starts-up, for example, during morning start-up, an RPC-to- 
UTM Agent 810 automatically starts running on server 804 
(step 8A). Next, RPC-to-UTM Agent 810 preferably queries 
a database 812 on server 804 to determine which devices 
connected to server 804 (in this particular example, storage 
controllers) require RPC-lo-UTM transport services (step 
8B). Preferably, database 812 stores a record for each device 
connected to server 804. The device records in database 812 
preferably include a field which indicates whether the device 
requires RPC-to-UTM transport services. For each device 
requiring RPC-to-UTM transport services, RPC-to-UTM 
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agent 810, starts an RPC connection listener 814 (step 8C). 
While the illustrated embodiment shows only one RPC 
connection listener 814, other connection listeners may be 
running on server 804. 

When a liser wishes to begin the device management 
process, the user preferably starts-up management station 
802, which starts a browser session 816 (step 8D). During 
the browser start-up process, the user preferably supplies the 
URL of the process-discover-monitor applet to be run. 
Browser 816 uses the URL to address an HTML page on 
web server 808. Alternatively, the URL may be stored in the 
browser or on the machine running the browser. Browser 
816 then contacts web server 808's HTTP server 818 and 
asks thai the discover monitor applet (DMA) be transferred 
to browser 816 (step 8E). In accordance with a preferred 
embodiment of the invention, HTTP server 818 retrieves the 
DMA program from an applet repository 820 on web server, 
808 (step 8F) and sends the DMA program to browser 816 
(step 8G). 

In accordance with an alternative embodiment of the 
present invention, instead of HTTP server 818 sending the 
actual DMA program to browser 816, HTTP server 818 may 
send an HTML page to browser 816, notifying the browser 
of the location of the DMA program. Then, browser 816 
preferably retrieves the DMA program from the specified 25 
location. In the illustrated embodiment, the location of the 
discover-monitor applet happens to be on web server 808. 
However, as discussed previously, the discover-monitor 
applet may reside in a repository stored on one or more 
storage systems residing on the network. In addition, while 
the start-up process discussed herein refers to an HITP 
server sending HTML pages to browser 816, other start-up 
procedure may occur. For example, communication proto- 
cols and languages other then HTTP and HTML may be 
used. Finally, while the illustrated embodiment shows web 
server 808 being separate from management station 802, the 
present invention may be configured so that web server 808 
is part of management station 802. 

After browser 818 retrieves the discover-monitor applet 
program from applet repository 820, the discover-monitor 
applet 822 is invoked according to the standard browser of 
Java run-time environment protocol for starting an applet 
(step 8H). 

In accordance with one embodiment of the present 
invention, a user may utiUzc DMA 822 to discover each 
managed device connected to the network. In accordance 
with this particular embodiment of the invention, the user 
preferably enters the device into DMA 822, and DMA 822 
then starts a monitor 'thread 824 for the entered device. 
Preferably, there will be a monitor thread 824 for each 
device selected by the user. 

In accordance with an alternative embodiment of the 
present invention, discover-monitor applet 822 may be con- 
figured to automatically discover all the devices on the 
network. DMA 822 discovers all direct network attached 
devices and all servers on the network. Upon locating a 
server, discover-monitor applet 822 requests from the server 
a Ust of all storage controllers or devices it has associated 
with it. After locating all the devices on the network to be 
managed, DMA 822 starts a monitor thread 824 for each 
device (step 81). 

After initializing a monitor thread 824 for each discovered 
device, the monitor threads 824 preferably initiate a con- 
nection to their associated devices 806 by connecting to the 
RPC connection listeners 814 (step 8J). As discussed above, 
RPC connection listeners preferably are started on one or 
more servers 804 for each device 806 connected to the 
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servers and being monitored by the management station. 
Once monitor threads 824 are connected to RPC connection 
listener 814, RPC connection listener then creates an RPC 
agent thread 826 for servicing the connection (step 8K). 

In each device controller 806, a management protocol 
server 828 is listening for management protocol requests. 
Each management protocol server 828 is queried (via an 
RPC agent thread 826) for its associated device properties 
(step 8L). Using the information from this step 8L, RPC 
agent thread 826 notifies monitor thread 824 of the device 
properties of the associated device 806 (step 8M). In turn, 
monitor thread 824 then updates DMA 822 with the device 
properties (step 8N). Upon receiving the device properties, 
DMA 822 builds a device connection table, which gives, for 
each device, a list of connections into the device. The 
connection-to-device map may be one-to-one, or many-to- 
one. In addition, the device connection table may include 
information about which management application program 
is associated with each device. 

Finally, with all storage arrays discovered, and all com- 
munication links set up, discover-monitor applet 822 dis- 
plays the discovered devices on a display screen from which 
device specific storage management applications may now 
be launched. 

In addition to obtaining device properties from devices 
806, monitor thread 824, and RPC agent threads 826 for 
each device may be configured to monitor each device 806 
for configuration changes or other device events. In accor- 
dance with this aspect of the present invention, discover- 
monitor applet 822 prepares for event listening by starting a 
management protocol "event listener" thread, which detects 
events from the device via the "Hanging AEN" protocol. 
Monitor thread 824 on management station 802 preferably 
acts as the event listener thread, and starts the hanging AEN 
event in much the same way as the other RPC agent threads 
are started. That is, event listener thread or monitor thread 
824 in management station 802 establishes a connection to 
the RPC connection listener 814 in server 804 (step 8J), 
which initiates an RPC agent thread 826 (step 8K). For 
device monitoring, the agent thread 826 preferably is con- 
figured for hanging AEN listening, and thus, initiates a 
hanging AEN listen primitive on controller 806, and in 
particular management protocol server 828. 

In accordance with a preferred embodiment of the present 
invention, the hanging AEN listening threads exist until an 
event occurs on a device 806. For example, if the configu- 
ration of device 806 changes for any reason, the hanging 
AEN agent thread 826 will detect the change and notify 
monitor thread 824 of the change (step 8M). 

Monitor thread 824 then will update the device charac- 
teristics of device 806 on DMA 822 which then displays the 
configuration change status on a display associated with 
DMA 822 (step 8N). After the update, DMA 822 then will 
start another hanging AEN thread for thai device. A more 
detailed discussion the event notification process is dis- 
cussed below in the section entitled Event Reporting. 
Management Interface Application Start-up 

Still referring to FIG. 8, flow diagram 800 also illustrates 
the start-up procedures for a management interface applica- 
tion. As discussed previously, discover-monitor application 
or applet 822 preferably discovers and lists all devices 
and/or storage systems connected on a network. For this 
particular example, the devices wUl be storage system 
devices. To start a management interface application for any 
of the storage systems on the network, the user preferably 
double-clicks on one of the storage systems when viewing it 
in the discover-monitor application (DMA) screen (step 80). 
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Next, DMA 822 preferably receives device properly infor- 
mation about the selected storage system device from a 
device property storage area (not shown). 

Included in the device properties is the storage system's 
management interface version (i.e., the management appli- 
cation program associated with that device). Next, DMA 822 
retrieves from applet repository 820 residing on web server 
808 or some other location the management interface appli- 
cation program version specified in the device properties for 



proper RPC Connection Listener 814 and/or RFC Agent 
Threads 826,834 associated with the proper device 806. 

In accordance with yet another embodiment of the present 
invention, instead of server 804 having demultiplexing 
software for directing commands to the proper device 806, 
server 804 may include a device mapper for allocating IP 
addresses to the connected devices 806. For example, in 
accordance with one particular embodiment of the invention 
which Mses a device mapper, the device mapper, which 



the selected device (steps 8P-8R). Preferably, the manage- lo preferably runs on server 804, locates all devices 806 



ment interface applicalioo program is a Java applet which is 
loaded into and run on management station 802 using a web 
browser or other suitable Java run-time environment. After 
retrieving the management interface application program 
from repository 820, DMA 822 then launches the manage- 
ment interface application 830 for the selected storage 
system (step 8S). 

Once started, management interface application 830 pref- 
erably starts a management interface application RPC han- 
dler 832, which controls the communication of RPC com- 
mands between management apphcalion 830 and server 
804. Management interface application RPC handler 832 
then starts an RPC agent thread 834 on server' 804, which 
facilitates communication between management interface 
application 830 and device 806 (step 8Y). Next, using RPC 
agent thread 834, management interface application 830 
retrieves the selected storage system's internal object orga- 
nization residing on controller 806 of the storage system 
(step 8Z). With this information, management interface 
application 830 knows how to connect to management 
protocol server 828 running in the storage system controller 
806. The object graph received from storage system con- 
troller 806 identities the objects comprising the storage array 
and their interrelationships. For each object in the object 
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connected to server 804. For each device 806 found, the 
device mapper allocates a dedicated TCP/IP port to it and 
saves the device -to-por I association in a device-to-port map. 
When discover monitor applet 822 discovers all the devices 
806 on the network, the device -to-port association is pro- 
vided to DMA 822 from the device-to-port map located on 
server 804. The DMA 822 then uses the device -to-port 
association lo send management commands to a particular 
device 806 connected to server 804. 

FIG. 8 illustrates how discover-monitor applet 822 locates 
and communicates with devices (e.g., storage controllers) 
proxy connected to a network through a server. While not 
discussed herein, a similar procedure preferably is used to 
locate and communicate with devices direct attached to the 
network. However, as discussed above, the RPC-to-UTM 
agent server 810 is not needed in the network attached case 
because the network attached controller includes firmware 
for receiving and translating RPC commands directly. 
Volume Creation 

Referring now to FIG. 9, a flow diagram 900 is shown 
illustrating the steps of creating a new volume on a storage 
system. If a user wTshes to create a new volume on a storage 
system, the user preferably selects.the new volume option 
shown on the display screen (step 9 A). Next, the man age - 



graph, management interface apphcation 830 preferably 35 ment interface application 902 fetches a list of "volume 

initiates a proxy object to represent the storage system's candidates" from storage system controller 904. The storage 

object graph on management station 802. That is, manage- system controller reports a list of volumes that can be 

ment interface application 820 stores a copy of the storage created, given the current drive group configuration of the 

system's object graph on management station 802, so it can storage system (see step 9B). Management interface appli- 

access and display the object graph when necessary. After 40 cation 902 then displays the new volume candidates on 



retrieving the storage systems organization and 
configuration, management interface application 830 dis- 
plays the storage system's configuration on a display screen. 

When a user wants to change the configuration of one of 
the devices on the network, for example device 806, the user 
instructs the management interface application 830 to ini- 
tiate the change (step 8W). Management interface applica- 
tion 830 then passes the change request to RPC handler 832 
(step X), which issues the request to RPC agent thread 834 
as an RPC command (step 8Y). RPC agent thread then 
encapsulates the RPC change request into a UTM packet and 
transmits the change to the controller of device 806 (step Z). 
Device 806 preferably processes the change request and 
sends a status update information back to management 
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display 906 to the user as "volume creation options" (step 
9C), Next, the user picks and possibly customizes one of the 
volume creation options (step 9D). This "new volume speci- 
fication" is supplied as an input to the management interface 
apphcation 902. The management interface application 902 
converts the new volume .specification input by the user into 
a "create volume" command which can be understood by the 
storage systems controller 904 (step 9E). Controller 904 
creates a new volume, and records that event in an array 
event log 908 (step 9F). As soon as the new volume is in a 
"committed", usable state, the "create volume" command 
returns to management interface application 902 (step 9G). 
The controller then reports a "configuration changed" event 
to listening clients (steps 9H and 91). As flow diagram 900 



interface application 830. More detailed discussions of how 55 illustrates, more than one management client may exist on 



configuration change requests are processed are discussed 
below in the sections entitled Volume Creation, Configura- 
tion RcpHcation, and Long-Term Operations. 

In accordance with the embodiment of the present inven- 
tion described herein, preferably server 804 includes demul- 
tiplexing software for routing management commands to the 
proper device 806 attached to server 804. Because devices 
806 are attached to the network via server 804, management 
commands directed to devices 806 are sent to the IP address 
of server 804, not the IP address of the devices 806. Thus, 
server 804 includes intelligence (preferably built in 
software) for directing the management commands to the 
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the network. In the illustrated embodiment, there are two 
management clients, 902 and 910. However, any number of 
management clients may exist on the network. 

When each of the clients 902, 910 receive the "configu- 
ration changed" event, clients 902, 910 preferably update 
their respective storage system screen displays 906, 912, 
showing that the new volume is in a state of "optimal - 
initializing" since, although usable, it does not have good 
parity (step 9J and 9K). Controller. 9 04 then initiates parity 
initialization on the new volume. Since the new volume is 
reported as being in the "initializing" slate, management 
clients 902, 910 display a progress bar for the parity initial- 
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ization task on display devices 906, 912 (steps 9N and 90). 
Clients 902 and 910 periodically request progress data from 
controller 904 and use that information to update the dis- 
played progress bar (steps 9P and 9Q). When the parity 
initialization task completes, controller 904 transmits a 
"configuration changed" event to clients 902, 910, indicating 
that the new volume is in the "optimal" stale (steps 9R and 
9S). Clients 902 and 910 then indicate on display devices 
906 and 912, respectively, that the parity initialization task 
is complete (steps 9T and 9U). Management clients 902, 910 
may display the task complete status in a variety of ways, 
including advancing the progress bar to 100%, dismissing 
the progress bar or displaying a message that the task is 
complete. 

Configuration Replication 

Referring now to FIG. 10, a flow diagram 1000 is shown 
illustrating the process of replicating a storage system con- 
figuration from one storage system to another. To replicate 
the configuration of one storage system to another, a user 
preferably selects a source storage array and invokes a 
management interface application 1012 for that system (step 
lOA). Preferably, the user uses the discover-monitor applet 
1010 running on management station 1002 to invoke the 
management interface application 1012. Next, the user 
selects a destination storage array which is to receive the 
source storage array's configuration, and invokes a manage- 
ment information application 1014 for that array (step lOB). 
Again, the user preferably uses the discover-monitor applet 
1010 in management station 1002 to invoke the destination 
storage system's management interface application 1014. 
Next, the source storage system's management interface 
application 1012 preferably fetches the device configuration 
description for the source storage system from storage 
system 1004, and in particular, controller 1016 (step 10 C), 
and writes it to file 1018 (step lOD). 

In the next step, the destination storage system's man- 
agement interface application 1014 is directed to "apply" the 
saved configuration description to the destination storage 
system 1006 (step lOE). In accordance with this aspect of 
the invention, destination storage system management inter- 
face application 1014 preferably displays a confirmation 
dialogue on display 1020 so that the user can confirm the 
application of the configuration description (step lOF). 
To update destination storage system 1006 with the source 
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have an operation which can perform management functions 
on a plurality of devices at the same time. In accordance with 
the present invention, any particular management command 
can be performed as a mass operation on a plurality of 
devices. However, for illustration purposes, the mass opera- 
tion model will be described herein as a mass configuration 
replication. However, the present invention is not limited to 
the specific example. 

Referring now to FIG. 11, a flow diagram 1100 of a mass 
configuration replication operation is shown. To initiate the 
mass configuration replication operation, a user 1110 pref- 
erably utilizes a discover-monitor application 1112 running 
on management station 1102 to select a source storage 
system 1104 and launch a management interface application 
1114 for the selected source storage system 1104 (steps 11 A 
and IIB). Next, user 1110 preferably selects a "generate 
config file" or other similar task from management interface 
applications 1114 task menu (step 11 C). Management inter- 
face application 1114 then will process the "generate config 
file" task by requesting and obtaining the configuration 
description of the source storage system 1104 from its 
controller 1116 (step IID). Management interface applica- 
tion 1114 will then save the configuration description from 
the source storage system 1104 into a storage area 1118 (step 
HE). In accordance with one particular embodiment of the 
invention, user 1110 may edit the configuration description 
in storage area 1118 (step IIF). The editing function may be 
performed using discover-monitor applet 1112, management 
interface application 1114, or another suitable editing apph- 
cation program which may reside on management station 
1102. 

After the configuration description is finalized, user 1110 
preferably selects the mass operation function on discover- 
monitor applet 1112 (step 11 G). Discover-monitor applet 
1112 retrieves the configuration description from storage 
area 1118 (step IIH), and then loads from a second storage 
area 1120 a list of storage systems on the network which 
may be destination systems to receive the mass configura- 
tion operation (step 111). Discover-monitor applet 1112 then 
displays the list of storage systems on the network on a 
display device 1122 (step UJ). User 1110 preferably selects 
the storage systems which it would like updated with the 
source configuration description (step IIK), and discover- 
monitor applet 1112 then launches management interface 
applications 1124-1 to 1124-N for each of the selected 



storage system's configuration, the destination system 1006 45 storage systems (step UL). As with the configuration- 



first should be synchronized with the source storage system 
1004 with respect to firmware sets. Thus, management 
interface application 1014 preferably retrieves the firmware 
that it needs for the destination device 1006 from a firmware 
repository 1022 residing on a web server 1008 or other SO 
suitable storage location (step lOH). The selected firmware 
is then loaded into the destination device 1006 and, in 
particular, controller 1024 (step 101). Next, management 
interface application 1014 passes the rest of the configura- 
tion description to controller 1024 on destination device ss 
1006 (step lOJ). Upon receiving the configuration 
description, the destination device 1006 then reconfigures 
itself, issuing "config change" events and "new task" events 
as appropriate (step lOK). 

Mass Operations 60 

As one skilled in the art will appreciate, it may be 
preferably to perform a specific management task on a 
plurality of systems on a network. For example, instead of 
performing a configuration replication on a single system as 
discussed above with reference to FIG. 10, it may be 65 
desirable to perform the configuration replication on a 
plurality of devices at the same time. Thus, it is desirable to 



application process illustrated in FIG. 10 and discussed 
above, each of the management interface applications 1124 
retrieves a firmware set from firmware repository 1128 in 
server 1108 or other suitable storage location (step IIM), 
and applies the controller firmware set to the controller 1126 
of the appropriate destination device 1106 (step 11 N). For 
example, management interface appUcalion 1124-1 prefer- 
ably retrieves a firmware set and applies it to controller 
1126-1 of destination storage system 1106-1. Similarly, 
management interface application 1124-2 retrieves a firm- 
ware set and applies it to controller 1126-2 of destination 
device 1106-2, and so on. 

After each of the controller firmware sets have been 
updated, each of the management interface applications 
1124 send the configuration description to the destination 
devices 1106 and their controllers 1126 (step 110). Control- 
lers 1126 receive the configuration description, perform the 
configuration change operation(s) and then pass back "con- 
figuration" and "new task" events to the management inter- 
face applications 1124 (step HP). 

As one skilled in the art will appreciate, before a con- 
figuration change is implemented, error checking typically is 
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performed to detennine whether the destiaation device is Once the RPC-to-UTM agent thread is started, the man- 
compatible with the configiiration description. That is, agement station preferably issues an RFC command, such as 
whether the particular hardware of the destination storage a "GetConfigChangelnfo" command or the like to the RFC- 
system can accept and implement the configuration set forth to-UTM agent thread 1308 (step 13 C). RPC-to-UTM agent 
in the configuration description. In addition, the software in 5 thread 1308 converts the "GetConfigChangelnfo" RFC 
the controller should be checked to determine if it can packet or other suitable command packet into a UTM buffer 
perform the functions required to implement the configura- ^nd forwards it on to storage system 1304 as a UTM 
tion update. In accordance with this particular aspect of the transaction (step 13D). Preferably, storage system 1304 
invention, an error checking routme 1200 as lUiKtrated m includes a controller 1310 and a UTM-to-internal- 
FIG. 12 may be used. Error checking routine 1200 prefer- ^^^^^^g component 1312. As one skilled in the art will 
ably comprises a hardware check module 1202 which ,,^,1, UTM -to-internal-messaging component may be 
re neves hardware confi^ration rest ramts from t^^^^^^^^ ^.^^.^ controller 1310. UTM-to-intemal- 
ration description 1204 (step 12A). In addition, hardware ^ ,11-.^ r ui 4U .i/^ * 
check module 1202 preferably retrieves the target or desti- ^^f^!^^ component 1312 preferably receives the Get- 
nation hardware configuration 1206 from the desUnatioo ConfigChangelnfo command via Um and starts a hanging 
hardware device (step 12B). Hardware check module 1202 ^5 AEN event 1314 (step 13E). 

then performs a check to determine whether the hardware The hanging AEN event is an evem 1314 which waits for 

target configuration is compatible with the configuration an event notification firom the storage system before any 

restraints from configuration description 1204. That is, hard- status is returned to server 1302, and the management 

ware check module 1202 determines whether the target or station. When an event within storage system 1304 occurs, 

destination hardware device can be configured according to 20 controller 1310 delivers an event notification to UTM-to- 

the hardware configuration restraints. If not, hardware check internal-messaging component 1312 (step 13F). When the 

module 1202 displays an error message on a display 1208 event notification is received, UTM-to-interaal-messaging 

(step 12C). If there is no error, the error check routine moves component 1312 configures the event notification informa- 

on to software check module 1210 (step 12D). tion into a suitable UTM packet and retrieves the "GetCon- 

Software check module 1210 preferably retrieves the 25 figChangelnfo" call from its hanging status (step 130). 
configuration specification 1212 from configuration descrip- UTM-to-internal-messaging component 1312 then returns 
tion 1204 (step 12E), as well as the destination device's the event notification information as a UTM packet or buffer 
software version specific rules 1214 (step 12F). The desti- 1316 to the RPC-to-UTM agent 1308 (step 13H). The AEN 
nation device's software version specific mles preferably set listener in RPC-to-UTM agent 1308 extracts the event 
forth the functions which the destination device's software 30 information from the UTM buffer 1316 (step 131), and then 
can perform. If the device's software version cannot perform writes the event information to a RFC message buffer 1318 
a particular configuration update, software check routine (step 13J). RPC-to-UTM agent 1308 then retums the "Get- 
1210 displays an error on display 1208 (step 12G). If the ConfigChangelnfo" RFC function to the management sta- 
software can perform the configuration change, the error tion along with the event notification information in buffer 
routine moves on to the apply configuration module 1216 35 1318 (step 13K). After processing the event notification 
(step 12H). Apply configuration module 1216 preferably information, the management station sends another "Get- 
retrieves the configuration specification 1212 from descrip- ConfigChangelnfo" function call in order to start the event 
tion 1204 (step 121) and uses it to perform the configuration notification process again (step 13L). Again, the RPC-to- 
change (step 12J). Preferably, the apply configuration mod- UTM agent 1308 then sends the "GetConfigChangelnfo" 
ule 1216 comprises the discover monitor applet, manage- 40 command in UTM format to UTM-to-intemal messaging 
ment interface applications, and other management applica- component 1312 in storage device 1304 (step 13M). The 
tion programs discussed above with reference to FIGS. 9, 10 hanging AEN event will then initiate until another notifica- 
and 11 above. tion occurs. 

While the error routine set forth in flow diagram 1200 is The event notificafion example illustrated in FIG. 13 and 

described in the context of a configuration replication 45 disclosed herein refers to a "GetConfigChangelnfo" com- 

example, one skilled in the art will appreciate that the error mand issued by the management sution. One skilled in the 

routine or a similar error routine may be performed on any art will appreciate that the "GetConfigChangelnfo" com- 

mass operation management function. In addition, the error mand is merely an example of a specific command (hat may 

routine set forth in FIG. 12 and described herein may be be used and that any other suitable command which server 

performed on other non-mass operation management 50 1302 and storage system 1304 can interpret as a command 

functions, such as the volume creation example illustrated in to begin the event notification process can be used. In 

FIG. 9 and the configuration replication example illustrated addition, the example illustrated in FIG. 13 is an event 

in FIG. 10. notification example for a proxy attached storage system 

Event Reporting connected to a network through a server. A similar event 

Referring now to HG. 13, a flow diagram 1300 is shown 55 notification process can be used with a network attached 
illustrating the process of a managed device reporting events storage system, except that instead of the RPC command 
to a management station. To begin an event reporting/ first being converted to UTM before being sent to the storage 
monitoring session of a proxy attached storage system or system, the network attached storage system will receive the 
device, a management station (not shown) preferably sends "GetConfigChangelnfo" command in RPC form firom the 
a "connect" command to server 1302 and more specifically 60 management station and processors it accordingly. That is, a 
to RPC-to-UTM agent server 1306 (step 13A). After receiv- RFC-to-intemal messaging component receives the com- 
ing the "connect" command, RPC-to-UTM agent server mand and starts the managing AEN event. 
1306 preferably creates an RPC-to-UTM agent thread 1308 Configuration Update Notification 

to service the connection (step 13B). In accordance with a In accordance with a preferred embodiment of the present 

preferred embodiment of the present invention, the RPC-lo- 65 invention, when a managed entity, such as a storage system 

UTM agent thread preferably is a dedicated hanging asyn- or other suitable I/O device on a network undergoes a 

chronous event notification (AEN) listener. configuration change, it is preferable that the configuration 
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change for that managed device is broadcast to all manage- and receiving configuration change notification information 
ment entities on the network. As discussed above, a given is illustrated. In accordance with this aspect of the present 
network can have a number of management entities such a invention, the management entity preferably includes a user 
one or more management stations in accordance with the interface 1502, which aUows a user to visualize the con- 
present invention, as well as DMI, SNMP or other third 5 figuration and status of the managed devices on the system, 
party management stations. Thus it is preferable to have a well as issue management commands such as volume 
system and a method in which a managed entity can notify changes configuration changes, and/or error recovery 
all management entities on a system of a configuration *^onimands, to name a few. To visualize the configuration 

change. In accordance with this preferred aspect of the JSj/'j*"", " P^?^^ ^f^' ""7 \ 

^ . o lAnn- 1. -11 . 1502 displays an object graph 1504 of the particular man- 
present invention a flow diagram 1400 is shown il ustrating lo device When a user wishes to change the configuration 
a process in which a managed entity 1404 mforms all ^ particular managed device, the user, using interface 
management entities 1402 on a system of configuration ^gpj, preferably issues one or more configuration change 
changes. commands from a command issuer 1506. As illustrated in 
As discussed above, a role of the management entity 1402 pjQ ^jj^^ command issuer 1506 issues a configuration 
is to keep and maintain an internal representation of the state 15 change or error recovery command, it does not wait to 
of managed entities 1404 on the system. This internal receive the configuration change information from the man- 
representation of a managed entity 1404 is referred to as an aged device. Instead, the management entity preferably 
"object graph." Management entity 1402 builds the object includes an event notification receiver 1508, which is con- 
graph by importing state information from managed entity figured to receive that information. When the managed 
1404. In accordance with a preferred embodiment of the 20 device's configuration is updated, the managed device issues 
invention, when the configuration of a managed entity 1404 update notifications to all management entities on the 
changes, the managed entity 1404 preferably transmits an system/networic. The management entities receive these 
entirely new object graph to management entity 1402. notifications via event notification receiver 1508. As dis- 
Managemenl entity 1402 then uses the new object graph to cussed above, the update notifications from the managed 
update the visual representation of the managed entity on a 25 devices may comprise entirely new object graphs from the 
display screen. managed devices, or the update notifications may be con- 
In accordance with an alternative embodiment of the figuration deltas which merely reflect the change in the 
present invention, instead of transmitting entirely new object configuration, 
graphs to management entity 1402 when a configuration Long-Term Operations 

changes, management entities 1404 preferably update the 30 When performing configuration altering commands to a 

object graphs in management entity 1402 by transmitting managed device such as a storage system or the like, two 

call back deltas. These deltas specify the specific part(s) of models of completion are common. The first model involves 

the object graph which have changed, so that as small a command which only takes a short time to complete. With 

changes to the object graph are made, only the information this model, the storage system controller can return status of 

about the small changes to the object graph are sent to 35 the short-term configuration request to the requester, as well 

management entities 1402, not completely new objects as other management devices in a system in near real time, 

graphs. This allows the object graph changes to be localized, The second model, however, involves a request that requires 

and thus, state information transfers minimized. an extended time to complete. For example, a complete 

For example, as discussed above with reference to FIGS. reformat or re-layout of data on a storage system. The 

9-13, when a management interface application is mn for a 40 problem with an extended time to complete type request is 

particular managed device or entity, such as a storage that the user expects to see a progress indication of (he 

system, the object graph of that storage system or managed command request to avoid uncertainty of a "hung" system, 

entity is typically displayed on the management station. However, if a management station thread is left open lo 

When changes to the managed entity are performed by a monitor the progress of the long term event, resources may 

management station, such as volume creation (FIG. 9) or 45 be wasted because a management station thread is hung-up 

configuration changes (FIGS. 10-12), the new configuration monitoring the status of the long-term command. Thus, in 

information typically is transmitted back to the management accordance with the present invention, systems and methods 

station requesting that change when the configuration are provided in which typically long-lived operations are 

change is complete. However, in accordance with this par- turned into short-term events. 

ticular aspect of the present invention, it is preferable that 50 In a typical transaction model for storage arrays, a man- 

the updated object graph deltas are independent from the agement station will not be freed until the storage array 

configuration change requests. That is, when a management "commits" a particular request or transaction. When a stor- 

station issues a configuration change command, it does not age system commits a transaction, the transaction typically 

wait for the command to finish before performing other is "durable". A durable transaction means that the storage 

tasks. Instead, the management station preferably issues an ss system guarantees that subsequent faults or interruptions on 

event notification session as discussed above with reference the storage system will not affect the results of the transac- 

to FIG. 13, and receives object graph update deltas via that tion. However, in accordance with the present invention, just 

path. In addition, all other management stations also will because a particular transaction is durable does not mean 

have event notification sessions running, so that they also that the storage system has finalized processing of the 

will receive the object graph update deltas when the updates 60 transaction, and thus, updated its configuration. As one 

occur. In this manner, all management stations are updated skilled in the art may appreciate, a transaction can commit 

with configuration change information as the changes occur early, but the transaction may still have residual activities 

or shortly thereafter. In addition, the management station that go on within the storage system after the storage array 

issuing the change request is not held-up, waiting for the has committed the transaction. These residual activities do 

change to occur. 65 not affect object durability, but may affect object state. That 

As illustrated in FIG. 15, a process flow 1500 of a is, the transaction request may be durable, but the storage 

management entity sending configuration change commands system reconfiguration may not be complete. 



09/06/2003, EAST Version: 1.04.0000 



us 6,584,- 

25 

Referring qow to FIG. 16, a flow diagram 1600 is shown 
illustrating a method of processing long-lived operations. In 
accordance with flow diagram 1600 in FIG. 16, a host or a 
management station preferably issues a long-lived operation 
request, such as a storage system drive reconfiguration, or S 
the like, to a managed device's controller (step 1602). In 
accordance with this example, the managed device prefer- 
ably is a storage system. However, any suitable managed 
device on a network may perform the long-lived processing 
operation of the present invention. lO 

After the management station issues the long-lived opera- 
tion request, the controller of the storage system receives the 
request (step 1604), processes the request, and makes nec- 
essary state changes to make the long-lived operation 
"durable" (step 1606). While the storage system controller is 15 
processing the request, and making the operation durable, 
the management station preferably waits for a response from 
the controller indicating that the request is durable (step 
1608). After the long-lived operation is durable in the 
storage system controller, the controller preferably returns 20 
status to the management station (step 1610). The manage- 
ment station receives the return status as complete (step 
1612) and displays a status complete dialogue to the user 
requesting the long-lived operation (step 1614). 

In accordance with the present invention, even though 25 
storage system controller returns status as complete, the 
complete status only indicates that the long-lived operation 
is durable within the controller. It does not mean that the 
actual long-lived operation has completed. Thus, the con- 
troller continues to process the long-lived operation (step 30 
1616) and send status updates of the operation to the 
management station or host (step 1618). The management 
station receives the status updates and preferably updates the 
completion status dialogue object displayed on the screen of 
the management station (step 1620). Steps 1618 and 1620 35 
continue until the long-lived operation completes. Once the 
long-lived operation completes, the storage system control- 
ler sends a completion message to the management station 
(step 1622). Upon receiving the completion message from 
the controller, the management station notifies the user that do 
the operation is complete (step 1624). The management 
station may inform the user that the operation is complete io 
a number of ways, including showing the completion status 
percentage as 100%, issuing a dialogue slating that the 
operation is complete, or ending the process. In any event, 45 
any particular status completion message may be used. 

Even though in step 1620 the management station 
receives status updates, and updates the completion status 
dialog on the management station screen, the management 
station is not frozen while waiting for the completion of the SO 
long-lived operation. That is, even though the management 
station displays the status information, a user may perform 
other tasks with the management station while the long-lived 
operation is processing. In addition, once the management 
station receives the message that the long-lived operation is 55 
"durable" even if the storage system fails, for example, due 
to power loss or some other mechanical error, the long-lived 
operation will be processed when the failed device is 
brought back on-line. In this matter, once an operation is 
made durable, the management station preferably docs not 60 
ever have to issue the long-lived operation request again, 
regardless of what happens to the controller. 

Conclusion 

In conclusion, the present invention provides methods and 65 
apparatus for managing I/O devices on a network. While a 
detailed description of presently preferred embodiments of 



499 Bl 

26 

the present invention have been given above, various 
alternatives, modifications and equivalents will be apparent 
to those skilled in the art. For example, while most of the 
examples given herein refer lo storage systems, any suitable 
110 device residing on a network may be managed using the 
methods and apparatus of the present invention without 
varying from the spirit of the invention. In addition, while 
preferred embodiments of the present invention are dis- 
closed herein as using Java applets and Java compUant 
browsers or run-time environments to process the Java 
applets, any suitable computer language and processing 
environment may be used. Therefore, the above description 
should not be taken as limiting the invention which is 
defined by the appended claims. 
What is claimed is: 

1. A method of configuring a plurality of managed 
devices, comprising the steps of: 

selecting a source managed device; 

invoking in a management station a source device man- 
agement application associated with said source man- 
aged device for monitoring and managing said source 
managed device; 

using said source device management application, obtain- 
ing a source configuration description from said source 
managed device; 

selecting one or more destination managed devices for 
being configured; 

invoking a destination device management application in 
a management station for each of said one or more 
destination managed devices, each of said destination 
device management applications being associated with 
at least one of said one or more destination managed 
devices, each of said destination device management 
applications for monitoring and managing said at least 
one of said one or more destination managed devices 
with which each of said destination device management 
applications is associated; 

said management station using said destination device 
management application for each of said one or more 
destination managed devices, issuing a configuration 
change command to each of said one or more destina- 
tion managed devices, so that said source configuration 
description selected from said som^ce managed device 
is applied to each of said one or more destination 
managed devices, 

2. The method as recited in claim 1, wherein said source 
managed device and said one or more destination managed 
devices are storage systems. 

3. The method as recited in claim 1, further comprising 
the step of editing said source configuration description 
before said step of issuing configuration change commands. 

4. The method as recited in claim 1, further comprising 
the step of determining whether said source configuration 
description can be applied to each of said one or more 
destination managed devices. 

5. The method as recited in claim 4, wherein said step of 
determining whether said source configuration description 
can be apphed comprises the step of checking said destina- 
tion managed device's hardware configuration lo determine 
whether said hardware configuration meets hardware con- 
straints of said source configuration description. 

6. The method as recited in claim 4, wherein said step of 
determining whether said source configuration description 
can be applied comprises the step of checking said destina- 
tion managed device's software to determine if said software 
can apply said source configuration description to said 
destination managed device. 
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7. The method as recited in claim 1, wherein each of said 
one or more destination managed devices includes a 
controller, and wherein said step of applying said source 
configuration description is performed by said controller of 
each of said one or more managed devices. s 

8. The method as recited in claim 7, further comprising 
the step of said controller of each of said one or more 
managed devices informing said destination device manage- 
ment application associated with said destination managed 
device that said configuration change request has been lO 
processed. 

9. The method as recited in claim 8, wherein said man- 
agement station, by miming one of said destination device 
management applications, is adapted to display a configu- 
ration and status of said destination managed device with 15 
which said one of said destination device management 
applications is associated on a display associated with said 
management station, said method further comprising the 
step of after said step of said controller informing said 
destination device management application that said con- 20 
figuration change request has been processed, said manage- 
ment station displaying a new configuration and status on 
said display for said destination managed device. 

10. The method as recited in claim 9, wherein said step of 
said controller informing said destination device manage- 25 
ment application that said configuration change has been 
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processed further comprises the step of transmitting a con- 
figuration change delta to said destination device manage- 
ment application, said delta comprising information on how 
said destination managed device's configuration has 
changed, said delta being used by said destination device 
management application to display said new configuration 
and status of said destination managed device. 

11. The method as recited in claim 9, wherein said step of 
said controller informiog said destination device manage- 
ment application that said configuration change has been 
processed further comprises the step of transmitting a con- 
figuration object graph to said destination device manage- 
ment application, said configuration object graph compris- 
ing information on the configuration and status of said 
destination managed device, said object graph being used by 
said destination device management application to display 
said new configuration and status of said destination man- 
aged device. 

12. The method as recited in claim 1, wherein said 
management station comprises a Java run-time environment, 
and wherein said source device management application and 
said one or more destination device management applica- 
tions comprise Java applets. 
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